Fixed a rare problem in the async transmit code where a "special ack" with an unknown error code would leave the FWIM in a semi-hung state.
DR5:
To the best of my knowledge, TI is officially encouraging people to ship only the newer version of the Lynx ASIC (known both as "rev 2" and "rev A"). Experience shows that it is much more reliable than the original. LynxFWIM contains some code to deal with bugs in the original Lynx part, but this code may be removed in the future.
Here are some performance notes that may be of interest:
* Because of the way headers are assembled for you, using SendPacketWithHeaderStart instead of SendPacketStart will save about four PCI accesses (in theory, up to ~50 microseconds, in practice, much less) per packet. For all but the smallest isoch transmit packets, you probably want to use SendPacketWithHeaderStart. Lynx can have considerable trouble keeping its FIFOs from overflowing and underflowing, so adding extra PCI latencies can make matters worse.
* When using callProcs in isoch transmit, keep in mind that the isoch transmitter works ahead. Your callProc function gets called after the previous packet has been loaded into the transmit FIFO. The packet may not have actually gone out on the 1394 bus yet, and if your packets are small, several of them may be waiting in the FIFO at once. The default iso transmit FIFO size is 512 bytes. Divide this by your packet size to find out how many might still be in the FIFO when your callProc runs. (callProc latency varies, so this may or may not matter for your application.)
* When assembling packets for isochronous transmission using one SendPacket[WithHeader]Start followed by some SendPacket commands, Lynx can use at most 13 buffers per packet. As implemented, LynxFWIM allows about 12 SendPacket commands after SendPacketWithHeaderStart, or about 9 after SendPacketStart. If your buffers cross page boundaries, the actual limit will be lower (one less for each page boundary crossing). If you can't predict page boundary crossings, then the most SendPacket commands you can safely use are about 6 after SendPacketWithHeaderStart or about 4 after SendPacketStart. For high perfomance, do not use any SendPacket commands at all, and for slightly better performance than that, make sure that the buffers you specify do not cross page boundaries. [Note that all of the page boundary rules apply regardless of whether VM is actually turned on or not.]
* When writing DCL programs for isochronous receive, similar limits apply with regard to multiple buffers for one packet, and page boundary crossings. Best receive performance is obtained with a single ReceivePacketStart for each packet, using a buffer that does not straddle a page.
* If you do know that a buffer straddles a page boundary, do not break it into two buffers with two DCL commands. LynxFWIM can do this for you with the same hardware performance, but with faster software performance and less memory consumption.
ReceivePacketOp is now supported (only ReceivePacketStartOp worked in DR4).
LynxFWIM now turns off its CycleMaster function much more quickly after a bus reset causes us to no longer be the root node. This prevents (or at least reduces) a period after a bus reset in which we have two cycle masters on the bus. This may also reduce the incidence of PHY jams. "revA" and later Lynx parts are supposed to not send cycle starts when they aren't on the root node, but it's not clear if this really works.
Note that the PHY jam recovery code in LynxFWIM needs work, and may not really recover correctly, especially if isochronous transfer is happening.
Considerable changes were made to the way we deal with ack values when transmitting (especially for FWWrite) and in what we do to control the ack values that we send to packets that are addressed to us. We now send ack_busyX if we run out of receive buffers, rather than sending no ack at all. We also retry ack_datErr in software and ack_busyX in hardware. The hardware retry has been made slower to give the victim more time to recover. Also, we do a better job of keeping our node number correct after a bus reset, so that we don't ack packets for other nodes.
Several routines have been added to read the serial EEPROM on Lynx. LynxFWIM will load the first 256 bytes of the EEPROM into part of the LynxFWIMData struct. LynxFWIM will also parse the EEPROM data to extract the global-unique-ID, and certain hardware config info such as the amount of SRAM present. This parsing may fail if the EEPROM is not formatted as suggested by TI/Solectron. The values found are stored in an EEPROM Info struct, but are not yet used, except for the global-unique-ID. If there is no meaningful global-unique-ID, one is faked up as before. Card designers should provide a mechanism for determining a global unique ID for every 1394 interface card, such as that provided by TI/Solectron in the serial EEPROM.
If you require information about the EEPROM format suggested by TI/Solectron, contact Apple Computer (or TI/Solectron). You can enable the debugStr calls in LynxFWIM to see what values it is pulling from the EEPROM.
DR4:
There was a change in LynxFWIM to more correctly locate the Lynx register base pointer. FWIMs for any device (Lynx, Pele, etc.) derived from this sample code should be modified to incorporate this change. See the function LynxFWIMGetRegisterBaseAddress.
DR3:
LynxFWIM has been extensively modified to reflect changes in the interfaces to the FireWire Services Library.
LynxFWIM now supports VM for all functions. There is some room for performance improvement.
Note that isoch transmit, as in DR2, is still hardwired to 100 mbits.
DR2:
The endless reset loop problem has been fixed.
Lock requests can now be processed and passed to higher layer software.
The LynxFWIM will now only set its root holdoff bit and enable cycle mastering when instructed to do so by higher layer software.
Isochronous packet reception has been improved. Higher layers of software have more control over how many and which isochronous channels are received and over the packet buffering mechanism. When isochronous reception ends, all final packets will be delivered.
Isochronous transmit is now supported.
Write quadlet request packets have been tested and work.
DR1:
LynxFWIM supports the prototype TI PCI-Lynx 1394 adapter card. Both the small TSBKPCI ("Light") and the big TSBKPCITST ("Deluxe") are supported. None of the deluxe features are used, except for the GPIO LEDs.
Devices attached to the bus at boot or after boot are usually recognized, but the process is not yet perfect. If a device seems to be missing, reset the bus (possibly by unplugging it and then plugging it back on). If a device still won't show up, try rebooting while it is attached. Finally, in rare cases, you may need to power-cycle your Mac (all Macs, if several are connected to one FireWire bus.)
If you connect two Macs to the same FireWire bus, best results are usually obtained by booting them simultaneously. However, hot attach should work most of the time too.
Sometimes when a DV camcorder is connected, the bus will get into an endless reset loop. This can be determined because "DV IN" may not appear on the camera, and the camera may not appear in the Name Registry. This can usually be fixed by power-cycling the camera. Leave the camera off for at least 5 seconds.
Lock request packets, if received, are not processed or responded to. But, LynxFWIM should be able to send lock transactions and receive responses to them. This has not been tested yet.
LynxFWIM sets the root hold-off bit, so Lynx often ends up as root. When self-ID packets are received, if Lynx is the root, the CYCMASTER bit is set, and Lynx sends cycle-start packets on the bus. If Lynx is not the root, CYCMASTER is cleared. Whichever device is root will need to send cycle-start packets in order for isochronous traffic to work. All known devices which set the root hold-off bit will send cycle-start when root.
It may be possible for Lynx's root hold-off bit to be cleared by a remote 1394 device. If this happens, LynxFWIM may not automatically restore the bit. As long as the remote device sets root hold-off, and is cycle-master capable, everything should still work - until the device is removed.
The prototype Lynx card is subject to certain failures which jam its operation. LynxFWIM can usually detect these and reset the card, after some delay. When this happens, packets are typically lost. This reset does not trigger a bus reset. This reset is also not always successful, so if the FWIM seems to be jammed, try rebooting.
LynxFWIM transmits at 100 megabits/second, except for packets with more than 400 bytes of payload data (block write), which are sent at 200 megabits/second. This is just a temporary hack. LynxFWIM will receive at both 100 and 200 megabits/second.
LynxFWIM receives all isochronous channels. This may cause performance loss if multiple channels are active, but not all need to be received. [This does not mean that you'll receive unwanted data from other channels - only that LynxFWIM will take time to look at and then discard the unwanted data.] It is known that if two isochronous channels are active, consuming about 60% of the bus, that the Lynx GRF will sometimes overflow, and packet reception will be unreliable.
Isochronous packets are received in groups of 16. When isochronous reception ends, up to 15 of the final packets may not be delivered. If the isochronous receive buffer overflows, approximately 32 packets will be lost. Also, some damaged packets may be delivered in this case. One way to cause an overflow is to use a time-consuming channel handler callback, which runs for more than 32 cycles (4 milliseconds).
If Asynchronous receive overflows, approximately 64 packets will be lost, and some damaged packets may be delivered. There is presently no known way to overflow the async receiver.
The largest asynch packet which can be transmitted or received is at least 628 bytes.
Isochronous transmit is not yet supported.
LynxFWIM processes write block and write quad packets, but sends no response. Write block has been tested extensively, write quad has not been tested.
The Open Transport DLPI cannot yet be used between a PCI-Lynx card and an old TI P1394 card, due to unresolved (software) differences in the handling of block data with zero-padding.
Only System 7.5.2 and 7.5.3 have been tested with LynxFWIM.
Virtual Memory must be turned off (this is true of all 1.0d11 components)
LynxFWIM blinks the LEDs on the (deluxe) PCI card to indicate what's going on. The LEDs are numbered 2 through 5, with 5 being closest to the ports (the numbers are silkscreened on the card, too). Here's what you can see in the LEDs:
2: Lights during Async receive processing
3: Lights during any transmit
4: Lights during Isoch receive processing
5: Inverts on each bus reset
Note: LED 2 lights during the software processing of received packets. This can include calls to handler functions, which could take a while, so LED2 tends to be bright. LED 3, on the other hand, lights only while we wait for the DMA to finish during a transmit - which isn't very long. So an equal number of same-sized reads and writes will not result in equal intensity of LED 2 and 3 - 2 will probably be brighter. Also, a single send or receive is about 1/8000 of a second or less, so you may only be able to see bursts. LED 4 lights during isoch processing, which includes channel handlers, which could also take a while, so LED 4 is often easy to see. LED 5 inverts on bus resets because a blink would be too fast to notice. However, some software events turn off LED 5, so it may not be a reliable indicator. (If it's blinking a lot, though, that's a good sign that something is wrong, or that someone is wiggling a loose cable.) These bits are toggled by software, so if you're in MacsBug, or hung, they won't work. All four LEDs default to on at boot - if they stay on, the FWIM did not load, or it broke very early.
[With the "Light" card, one could possibly connect a logic analyzer to the GPIO pins (pins 125-122) on the Lynx ASIC to see this status.]
These uses of LynxFWIM have been tested:
Adobe Premiere: Can receive 30 fps from the FireWire CCM-DS250/SS camera and display with no packet loss on machines with a 604 and an L2 cache. Can display (pixel-doubled) 640 x 480 in 16-bit color on a PowerMac 9500/150, if the display window is aligned on a 64-bit boundary. Can record at ~15 fps with no frame loss on a 7600/120 with L2 cache (16-bit color, may have to turn Sound recording off).
File Sharing: Can copy files of any size in either direction between any two machines. Can do two copies simultaneously (one on each machine). Performance is presently similar to 10mbit Ethernet. "Pulling" files works somewhat faster than "pushing".
Apple Media Conference: Can send (analog-in) video over FireWire / AppleTalk (tested case: 7600/120 to 9500/150). Can also use CCM as video input source to send video over Ethernet. Can even send CCM video over FireWire, though this is kind of silly. (This may cause GRF overflows, too.)
